1. Field
Embodiments relate to supporting multiple versions of a routine.
2. Description of the Related Art
Relational DataBase Management System (RDBMS) software using a Structured Query Language (SQL) interface is well known in the art. The SQL interface has evolved into a standard language for RDBMS software and has been adopted as such by both the American National Standards Institute (ANSI) and the International Standards Organization (ISO).
A query may be described as a request for information from a database based on specific conditions.
An SQL stored procedure may be described as a procedure written with SQL statements. The use of SQL stored procedures for business applications has brought about the need to provide capability to support the existence of and the maintenance of different variations of an SQL stored procedure for the development, test, and production environments. An SQL stored procedure is a type of SQL routine.
An SQL routine may be described as a database object that encapsulates procedural logic and SQL statements and is stored on a database server. An SQL routine may be a procedure (e.g., a stored procedure) or a function (e.g., a user defined function). A user-defined function may be described as a function defined by a user.
An SQL routine includes source code, executable code, and a definition. The definition is stored in a catalog, which is stored in a database and contains information about the database, such as descriptions of tables, views, and indexes stored in the database and that are referenced by SQL statements in the routine body. The source code may be described as including the body of the routine (also called the specification). Existing support of SQL routines requires that, in order to make a change to the body of the routine, the source code of the routine be maintained outside of a database. Furthermore, to make a change to the body of the routine, the definition is removed from the catalog in the database, changes are made to the routine specification, and then the routine is re-created with a new definition in the catalog. This support allows for a single definition of a routine at any point in time at the Relational DataBase Management System (RDBMS). Also, since existing techniques of changing the body require the routine to be ‘dropped’, there are undesirable effects, such as losing grants of privileges on the routine to other users.
Additionally, multiple variations of a routine may be defined and used today using the following mechanisms: 1) different high level qualifiers for the routine name or 2) different load modules or load libraries.
A high level qualifier may be described as a part of a name for a routine. For example, for a routine named ABC, high level qualifiers X and Y, respectively, may be added to different variations of the routine (e.g., X.ABC and Y.ABC may be names of the different variations of the routine). However, this may require that the entire qualified name be specified on invocation of the routine to ensure that the desired variation of the routine is used. In some cases, if the qualifier is not explicitly specified, then the RDBMS attempts to select the right qualifier using an SQL path. If the SQL path is properly setup, then the correct variation is invoked. The user can set the contents of the SQL path to affect which qualifier is chosen. Multiple variations of a routine may have differences in their parameter lists, and some of these differences may require the use of different high level qualifiers.
Outside of the database, multiple variations may be defined using different load modules or load libraries. In particular, a CREATE statement creating the routine may specify an external name (i.e., in an EXTERNAL NAME clause) that points to a particular load module that stores the routine. That is, the routine definition may specify (i.e., by an indirect link) the desired load module in the EXTERNAL NAME clause. However, both the load modules and load libraries are kept and managed outside of the database, which requires more management and more processing (e.g., to load the routine).
These conventional mechanisms for supporting multiple variations of a routine involve multiple setup steps and a level of complexity in the process for building the routine.
Therefore, there is a need in the art for improved support of multiple versions of a routine.